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INFORMATION TRANSLATION COMMUNICATION PROTOCOL 

FIELD OF THE INVENTION 

5 This application is a continuation in part of US application serial no. 

09/348,693, filed on July 7 5 1999, the contents of which are incorporated in their 
entirety. The present invention relates in general to a procurement system. More 
specifically, the invention relates to a procurement system where a user completes a 
structured requisition form based predominantly on pre-existing normalized 

10 relationships to order an item not available in a catalog database. The form is used to 
specify the desired item and to selectively create updated normalized relationships for 
use in identifying the new item so that it and similar items may be placed in the 
catalog database when free form data is examined using the normalized relationships. 
BACKGROUND OF THE INVENTION 

15 Procurement systems are well known. A buyer searches a catalog or a catalog 

database, locates material of interest, and places an order. A supplier then fulfills the 
order. However, special orders greatly complicate and slow down the entire 
procurement process as well as greatly increasing procurement expense. In practice, a 
buyer who cannot find an item located in a catalog must fill out a special requisition, 

20 also known as a special order request. However, no order is even placed until a 
potential supplier and related cost and delivery information is provided to the buyer 
for consideration. 

The requisition is then sent to a procurement fulfillment organization. A 
fulfillment specialist reviews the special requisition and manually determines if there 
25 are any potential suppliers that can fulfill the special requisition. Potential suppliers 
are then contacted and they respond accordingly. Each of the suppliers has their own 
way of describing the items it carries. Thus, the fulfillment specialist must manually 

1 
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review each supplier proposal and determine which ones appear to be most favorable 
to the buyer. 

Next, the buyer must receive the best proposals from the fulfillment specialist, 
determine which one appears to be the most appropriate for that organization, and 
5 manually go through a special order process for the special requisition to actually be 
fulfilled by a supplier. Worse yet, when the special order is finally fulfilled, all of the 
special effort that went into manually reviewing the requisition, manually determining 
potential suppliers, manually locating the best suppliers, and then actually fulfilling 
the special order is lost. Thus, the entire process must be re-initiated if a different 

10 buyer wants the same or a similar special order in the future. 

Thus, there is a strong need for a procurement system that takes into account special 
requisitions and resulting special orders, and uses the information related to such 
special orders so that the effort spent on fulfilling each order is not lost. In particular, 
it would be highly desirable to be able to receive a special requisition, and use a 

15 methodology to automatically select most likely suppliers without human 
intervention. If such an automatic selection process were available, then the special 
requisition could automatically be sent to each vendor for review and quoting. 
Moreover, it would be highly desirable to be able to receive the information from each 
supplier in a consistent format so that review of the received information could be 

20 automated as well according to pre-determined criteria to select the best supplier(s) 
for a possible special order. Additionally, it would be desirable to use the special 
expertise of both buyers and suppliers to create updated rules and item information 
associated with the special order. Therefore, future orders of the same item would not 
require the same special handling. 
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SUMMARY OF THE INVENTION 

An inventive procurement system according to the present invention takes 
advantage of the information transferred between a buyer, a procurement fulfillment 
organization, hereinafter called a back office, and a supplier to automate and 
continuously update a catalog database of items. 

In practice, a buyer searches for an item in one or more catalog databases 
using a parametric or text search strategy. If the item is not found, the user then 
creates a special requisition that will uniquely identify the desired item. The 
requisition is transmitted to the back office, which then forwards it to potential 
suppliers. One or more of the suppliers review and revise the requisition and send it 
back to the back office. The back office uses predetermined criteria to select one or 
more of the suppliers and then provides the buyer with the supplier information. The 
buyer may place an order for the special item. 

A key advantage of the present invention is that both the catalog database as 
well as the special requisition are normalized using predetermined rules related to 
class, attribute, and value relationships that are already known to the back office, and 
must be followed by the buyer to create the special requisition. Generally, these rules 
are stored in a knowledge base. When the back office receives free form item data, 
the free form data is processed through the knowledge base to create the normalized 
database that a user searches. The rules used to create the normalized database are 
made available to the buyer to locate a specific item. 

Thus, when making a special requisition for an item not in the database, the 
buyer first identifies the item using all available class, attribute, and value 
relationships used to create the normalized database. The remaining class, attribute 
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and value relationship information required to uniquely identify the desired special 
item are then suggested by the buyer and forwarded to the back office. 

The back office uses the pre-existing information identified by the buyer to 
pre-select potential suppliers that are already associated with the selected classes, 
5 attributes, and values and automatically forwards the special requisition to them. 
Thus, no human intervention is required. 

One or more of the suppliers review and revise the special requisition using 
the same relationship approach as followed by the buyer and dictated by the pre- 
£3 existing rules of the knowledge base and then returns it to the back office. Thus, at 

~ 10 least two experts (i.e., the buyer and the supplier) have proposed a revised 
Jj normalization relationship to uniquely identify a desired item in accordance with the 

m pre-determined rules. The revised normalization relationship may be used to create a 

O new rule for the knowledge base to process future items with no further human 

fy intervention. 

15 Moreover, by having a normalized item selection process, the desired item and 

related items may be readily added to a catalog database for future selection by other 
buyers. Such an approach takes advantage of the expertise of the buyer and supplier 
in fulfilling a special requisition while eliminating the need to undertake the same 
process for other buyers. The catalog database is automatically updated as required 
20 over time, generating catalog database updating in a real time fashion. 

Yet another advantage of having a normalized approach to the special 
requisition process is to permit easy item comparison by a buyer. When more than 
one potential supplier of a desired item is located, having the item information in a 
normalized fashion according to class, variable and value relationships provides easy 
25 comparison of the various items by the buyer. Thus, comparison-shopping is 
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expedited to the benefit of all parties since fewer returns are likely when the item 
criteria are clearly understood. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The features and inventive aspects of the present invention will become more 
5 apparent upon reading the following detailed description, claims, and drawings, of 
which the following is a brief description: 

Figure 1 is a schematic overview of key elements of the present invention 
including a buyer, supplier, and a back office with both the supplier and the buyer 
communicating with the back office. 
:j? 10 Figure 2 is a flow chart of a procurement system according to the present 

IS invention. 

sj Figure 3 is an example of an advanced search screen discussed with respect to 

s the present invention. 

Figure 4 is an example of the hits located from undertaking an advanced 
15 search according to the present invention. 
™ Figure 5 is an illustration of the class hierarchy of the normalized item data 

according to the present invention where if gases are selected, at least two sub-classes 
of gases are provided. 

Figure 6 is an example of a parametric search screen provided after a leaf class 
20 has been selected. 

Figure 7 is an illustration of a product comparison screen according to the 
present invention. 

Figure 7A is an illustration of a graphical based product comparison screen 
comparing the values associated with two different attributes with data points 
25 representing different items having the plotted values for the indicated attributes. 



5 



65,545-0074 




PATENT 



Figure 8 is a flow chart illustrating a preferred embodiment of a structured 
requisition subsystem according to the present invention. 

Figure 8A is an illustration of a structured product requisition form displayed 
on a computer screen. 

5 Figure 9 is a flow chart illustrating a preferred embodiment of a catalog update 

subsystem according to the present invention. 

Figure 10 is a representation of the relationships between the various elements 
of the present invention including the buyer, buyer interface application, back office 
(including catalog database, common language generator and knowledge base, and 
10 back office communications interface), and supplier/supplier interface application. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
A procurement system 20 is illustrated in Figure 1 that includes a buyer 22, a 
procurement fulfillment organization hereinafter referred to as back office 24, and 
suppliers 26. As shown by a communications link 28, buyer 22 communicates with 
15 back office 24 to search or select item information and to place an order. To facilitate 
the item order process, back office 24 has one or more catalog databases 32 that are 
normalized using a common language generator ("CLG") and corresponding CLG 
knowledge base 30, discussed in greater detail below. In turn office 24 communicates 
with suppliers 26 as shown by communications link 34 to get information not in its 
20 catalog databases 32 or to forward an order received from a buyer 22. Then the 
appropriate supplier 26 or its agent ships the requested item directly to buyer 22, 
fulfilling the order as shown by line 36. 

Procurement system 20 is illustrated in greater detail in Figure 2. First, buyer 
22 logs onto a buyer interface application 40, described in greater detail below with 
25 respect to Figure 10, at start point 42. Next, buyer 22 determines at decision point 44 
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if it will be selecting an item from a hot list. A hot list is typically a listing of items 
associated with a particular buyer 22 based on past purchase history or preferences. In 
some cases it may represent the purchase history or preferences of the buyer's 
organization. Unlike catalog databases 32, a hot list is typically stored within 
application 40 and periodically updated to take into account discontinued items and 
the like. Thus, a hot list is generally static. It may or may not include parametric 
information such as that discussed below. If it does not then a text search or browsing 
is required to find an item. If an item is selected from a hot list, it may include a 
dynamic link to a database 32 that the item originally came from, thus providing 
updated information such as pricing. 

If the desired item is found in the hot list as shown at decision point 52, then 
the user is next asked if there are any additional items to be ordered at decision point 
54. If yes, then the item selected is temporarily stored at point 56 and buyer 22 
returns to start point 42 to select the next desired item. If no additional items are 
desired then an order is created at point 58. Even if an item comes from more than one 
source such as a hot list or one or more databases 32, point 56 represents a common 
holding point such as a shopping cart. The option to modify the item selection is 
permitted at decision point 60. If an item is to be modified, then buyer 22 is returned 
to start point 42. Otherwise, any additional information is entered as required at point 
62 and the order is submitted at point 64. In many cases, specific approval is not 
required if the standard buyer catalog database 32 or a hot list 44 is used. In some 
cases, however, an approval process is required by the buyer's organization as shown 
at point 66. Once the order has been approved, it is then placed by the buyer's 
organization as shown at point 68. Back office 24 informs one or more suppliers 26 
who fulfill the order as shown by item 36, and discussed with respect to Figure 1. The 
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items are shipped to the buyer 22 according to buyer purchasing preferences. Finally, 
the procurement process ends at termination point 69. 

If an item is not found using the hot list at decision point 52, additional 
methods for locating a desired item are available. First, the user is returned to start 
5 42. If the hot list option is not selected, then at decision point 70 buyer 22 is asked if 
she will be using a standard buyer catalog database 32. If yes, then the standard 
database 32 is selected at point 71. Typically, a buyer accesses a standard buyer 
catalog database 32 that has been put together by his organization for routine 
purchases and that represents the purchasing preferences of the organization. If not, 

10 then additional database catalog(s) may be used as shown at point 72. One possible 
database is a cumulative global database representing all items tracked by back office 
24 for many suppliers and buyer organizations. Other databases 32 may include an 
intermediate catalog based on geography, subject matter or the like. For example, an 
organization may have a regional database 32 including items available in a specific 

15 geographic region that is searched before a master catalog acting as a cumulative 
global database 32 is searched. Different databases 32 may be available depending on 
the characteristics of the buyer 22 including company, geographic information, and 
even buyer classification within an organization. 

Once the desired database 32 has been selected, buyer 22 may conduct an 

20 advanced text search for a desired item as shown at decision point 74 and illustrated in 
Figure 3. As shown in Figure 3, buyer 22 may refine the area of searching be selecting 
a category as shown at point 76, enter a search string as shown at point 78, select 
Boolean operators such as "OR" and "AND" as shown at point 80, and even select 
specific parameter fields to search as shown at point 82. Finally, the number of hits to 

25 display is selected at point 84. The user then reviews the search results at point 86. An 
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example output according to one such search result is illustrated in Figure 4. Then the 
system continues at decision point 52 as discussed above. However, if an item is not 
located and the user chooses to search a different set of catalog databases, then again 
selecting advanced text search at decision point 74 will pull up the most recent search. 
5 Thus, all of the search information does not have to be re-added. 

More typically, however, a buyer 22 takes advantage of the normalization 
features of system 20 by navigating the organizational hierarchy of items stored 
within one or more databases 32 and uniquely identified using a class/attribute/value 
relationship rather than conducting an advanced search. Thus, if a text search is not 

10 conducted as shown at decision point 74, buyer 22 then selects item classes as shown 
at point 90. Buyer 22 drills down through the various item classes that are presented 
in a hierarchical format. As shown in figure 5, for example, selecting a class "gases" 
will present the sub-class under it. Selection of the sub-class will present the sub-sub- 
class and so on. The process continues as shown by decision point 92 until a leaf 

15 class (the last class in a class hierarchy) is selected. 

Once a leaf class is selected, a parametric search engine is presented as shown 
at point 94. The parametric search engine presents the attributes associated with a 
specific item leaf class and valid values associated with each attribute. The attributes 
can be presented in a variety of selection objects, such as drop-down boxes, list boxes, 

20 and sets of check boxes as shown in the example of Figure 6. The user selects the 
value and clicks an operator button. Within the Parametric Search, there is an undo 
button that removes the value in the search for items. 

Typically there are three types of attributes: static, differentiating, and 
dynamic. A Stock Keeping Unit ("SKU") represents a specific item as defined by its 

25 differentiating attributes. For example, if an item is a shirt with differentiating 
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attributes color and size, then blue XL shirt is a SKU. Static attributes define an 
intrinsic property of a product and do not vary based on a SKU. A differentiating 
attribute is an attribute that defines the uniqueness of a SKU. A dynamic attribute is 
an attribute that is associated with a product dynamically at buy time. 

Once buyer 22 has selected all available attribute values then the buyer must 
determine if additional specifying is required as shown at decision point 96. If no 
additional specifying is required then system 20 passes to decision point 98. At 
decision point 98 the use of the class/attribute/value approach permits a comparison of 
multiple items that meet the parametric search criteria and the selection of the item 
that meets the buyer's specific requirements as best illustrated in the example of 
Figure 7 and shown at point 100. When listing items for comparison, it is possible to 
have items matching the search criteria displayed using different rules associated with 
that database 32 such as a preferred vendor selected by the buyer 22. Each database 32 
may have its own preferred rules for displaying information. When more than one 
database 32 is being searched, the rules may be combined or the rules of one database 
32, e.g., the local catalog of the buyer 22, may take precedence over the rules of a 
second database 32, e.g. a master catalog being accessed by the buyer. 

While not illustrated in the Figures, item comparison may also be 
implemented when doing an advanced text search. By using the class/attribute/value 
approach, a consistent and specific determination of item elements is accomplished. 
In practice such an approach reduces buyer confusion regarding item features and 
provides a listing of all values available with respect to a specific attribute of interest 
to a specific buyer. 

As shown in Figure 7, additional item information may be reviewed by 
clicking on the hyperlink associated with the specific item. Moreover, information 
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about the merchant or supplier 26 may be determined by clicking on the hyperlink 
next to the item. Additional information such as item identification number, 
manufacturer, units of measure, and pricing is also illustrated. 

It is also possible to compare items at point 100 using a graphical approach. 
As shown in Figure 7A two attributes for notebook computer are being compared, 
namely processor speed versus price. Various models of notebook computers are 
plotted on the two dimensional graph. Moving a mouse over each data point reveals 
information concerning that item. For example, as shown in the Figure, the cursor is 
over the designation "Portege 7020CT", revealing a picture in the right hand portion 
of the screen of what the item looks like. While a two dimensional graph is shown, it 
is possible to compare more than two attributes at the same time. For example, a 
three-dimensional graph may allow a comparison of three attributes. 

A preferred embodiment of the invention permits the use of a text search 
option even when undertaking a parametric search. For example, a user may desire to 
quickly find out if a database includes blue pencils. Therefore, once a class for 
pencils is selected, a text search may be desired to determine if there are any pencils 
with the color blue, thereby bypassing the rest of the class, attribute and value 
determinations. 

To help a user determine the best balance between a parametric search and a 
text search, in a preferred embodiment of the invention additional information is 
provided as either a parametric search or a text search is undertaken. For a parametric 
search, under each class, the total number of children classes as well as the total 
number of items associated with the selected class is provided dynamically as part of 
an interactive feedback mechanism. As a user gets closer to a leaf class, the number of 
additional classes and the number of items associated with that class is reduced. For a 
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text search, feedback in terms of the number of items satisfying the search is provided 
interactively and dynamically as the buyer 22 types a search string at point 78 or 
enters various operators at point 80 or parameter fields at point 82. When a text search 
is undertaken as part of a parametric search, the number of items is based on the 
search parameters already satisfied with respect to the parametric search. Besides 
helping to further fine-tune a search strategy, a user is dynamically informed of 
problems including a mistyping or the use of unduly limiting Boolean operators. 

While Figure 2 shows comparing items at item 98, in a preferred embodiment 
of the invention, it is possible to provide a comparison table or graph even before 
either a leaf class or parametric values are entered, particularly if there is a sufficiently 
small number of items at the indicated level of the parametric search. Therefore, in a 
more preferred embodiment of the invention, there is a comparison feature at each 
level of a parametric search. A table generated by system 20 preferably includes a 
listing of attributes and the values for each attribute for a located item, as shown in 
Figure 7. The attributes typically represent column headers, and may be moved 
around or deleted as desired by a user. Alternatively, a graph may be generated as 
shown above with respect to Figure 7A. 

Then system 20 continues as discussed above at decision point 52 where the 
item may be selected for purchase by clicking the "Add" icon and the process 
continues as discussed above until the procurement process is complete. If an item is 
not located using the class/attribute/value relationship approach then the user is 
returned to start 42. As with the advance text search option, if the select class option 
is again selected the most recent leaf category will be provided to avoid the need to re- 
enter all of the search criteria. 
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As noted above, it is possible to select from a variety of catalog databases 32 
at point 72. If an item is not located during an initial search of previously selected 
databases 32, requiring a return back to start point 42, system 20 may be designed to 
automatically add pre-determined additional databases. In the alternative, a buyer 22 
5 may choose which databases 32 to search. In either case, the addition of different 
databases 32 after an initial search of one or more databases 32 is an example of a 
cascading search. 

To facilitate such a search, particularly when conducting a parametric search, 
in a preferred embodiment of the invention the various databases 32 include consistent 

10 classes, leaf classes, attributes, and values. Thus, information provided in an earlier 
search is passed to a later search, including the class node or path, attributes for the 
class, and the corresponding values for the attributes. For example, assume a user is 
looking for a blue pencil, but the usual database 32 does not include such a pencil. 
Moreover, assume that the first database searched includes an attribute called "Pencil 

15 Color", but lacks the value of blue. A different database 32 includes a pencil with all 
of the attributes and values located with respect to the first database 32, but includes 
the desired blue pencil. If that database is searched then the value "blue" will appear 
under the attribute called "Pencil Color" with the organization of the classes, 
attributes, and attribute values preferably the same. Thus, a user will only have to 

20 look under the appropriate attribute listing for "Pencil Color" since the search 
parameters will already be populated based on the earlier search. 

To populate a pre-existing search it is generally preferable to send the search 
criteria between databases 32 as opposed to bringing an entire catalog itself down to 
the location of a buyer 22. The search criteria are either sent to one or more different 

25 servers or possibly to one or more additional databases 32 on the same server as that 
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of the database 32 originally searched. The population of the search criteria can be 
done in parallel simultaneously against multiple catalogs as represented by databases 
32 to provide initial feedback to a user concerning the number of items that meet the 
search criteria for each of the available databases 32 as discussed above. When a 
5 buyer 22 selects particular catalogs or databases 32 to browse, that buyer is then 
typically presented with the parametric search screen for those products that match the 
search criteria found in those catalogs. 

While the present invention recognizes that protocols such as Extensible 
Markup Language ("XML") may be used to populate a search criteria, when a typical 
10 Internet web browser such as Internet Explorer or Netscape Communicator are being 
used, the search criteria are included in a Uniform Resource Locator ("URL") query 
string. 

A cascading search using a common hierarchy provides a number of 
advantages. For example, it makes it easier to copy search information when 

15 searching between databases 32 without requiring undue additional re-inputting from 
a buyer 22. Additionally, it permits synchronization between databases 32. It is easy 
to move items between databases 32 when they have a common hierarchical scheme. 
Moreover, a common interface may be provided to a user even when searching 
between different catalogs. For example, if search results are provided in a top frame 

20 of a web browser for a database 32, the same frame and output format may be used for 
a different database 32, where information about the second database may or may not 
be given. Thus, movement between databases 32 may be generally transparent to a 
buyer 22. 

While it is desired to have a common hierarchy scheme between databases 32, 
25 system 20 recognizes that it may be desirable to have exception lists between two 
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different databases 32. For example, an exception list may be used to provide 
translations between different languages. Thus, a class, attribute or value in one 
language will be compared with a translation table to permit it to be matched with a 
corresponding class, attribute or value in a second language associated with a different 
5 database 32. 

If a user desires additional specifying at decision point 96 of Figure 2, then 
structured requisition subsystem 102 is invoked as shown in Figure 8 to create a 
structured requisition. A key advantage of the invention is that buyer 22 has already 
reduced the scope of the item requisition through the familiar normalized selection 

10 process. Thus, in most cases item classes and sub-classes have likely been determined. 
In many cases, the classes have been determined all the way down to a leaf class. 
However, if the leaf class has not been selected as shown at decision point 104, then 
buyer 22 is provided with a revised selection screen from which she can select from 
available classes to further refine the item selection process as shown at point 106. 

15 Unlike in the regular procurement process, however, the classes are not limited to the 
specified catalog database 32. Instead all the classes from the master or global catalog 
database 32 are made available to the user to expedite the item location process. 
Additionally, attribute and even value information may be made available from the 
master or global catalog database 32. 

20 If a leaf class has already been selected or once a leaf class is determined, then 

a modified parametric search screen with the most recently selected acceptable class is 
provided at point 108. It may also include the pre-selected attribute and even value 
information. Similarly, unlike the regular item selection process discussed above, the 
attributes and value selections are not restricted to the database 32 originally selected 

25 by the buyer 22. Instead, they include all possible attributes and values for a selected 
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leaf class in all catalog databases 32 available from back office 24. Thus, in many 
cases, a user will not have to manually enter any additional information into the 
modified parametric search screen. However, unlike the screen shown in Figure 6, as 
shown at point 110 buyer 22 has the ability to add new values for any selected 
attribute to better identify a desired item as shown at point 112. For example, if a 
faster CD ROM drive is required, buyer 22 can add the speed of the drive required as 
a new value. Moreover, if a required attribute, such as screen size, is missing, the 
buyer may be given permission to add the newly desired attribute along with a desired 
value. In some cases, a buyer 22 may even be able to propose a new class hierarchy. 
Under all circumstances a memo field is also provided for clarification of item 
requirements even if a buyer 22 is limited to only proposing new attribute values. 

An example of a structured requisition form is illustrated in Figure 8A. As 
shown in Figure 8A, it is possible to select from a drop down menu of available 
choices or manually enter a value for a given attribute (called a feature in the Figure). 
There is also a memo field available for additional information not represented by the 
available attributes. In some cases it may be possible to include in the memo field the 
contents of a text search conducted before getting the structured requisition page or 
even other free text information. More typically, however, only pre-selected 
parametric information in the form of class, attribute and value information is passed 
to the structured requisition form as discussed above. 

Once the structured requisition is completed at point 114, it is submitted to 
back office 24 by way of communications link 28. Communications link 28 was 
discussed with respect to Figure 1, above. At the same time, buyer 22 is returned 
back to the calling point of system 20 at point 116 so that additional items may be 
selected or a partial order completed. 
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Upon receipt of the structured requisition at point 118, back office 24 reviews 
the requisition to determine if it is correct as shown at decision point 120. If not, then 
buyer 22 is notified at point 122 by way of link 28 and the structured requisition 
subsystem 102 terminates at end point 124. 

If the requisition is correct, then it is compared with all items in the master 
database 32 corresponding to the selected classes/attributes/values as shown at 
decision point 126. If one or more matches are found at decision point 126, 
communications link 28 provides the purchase information to buyer 22 for order 
submission at point 128. In a preferred embodiment, an electronic mail message is 
sent to buyer 22 with a hyperlink that will be recognized by a web browser such as 
Netscape® Navigator or Microsoft® Explorer. Buyer 22 clicks on the hyperlink and 
is routed to a screen very similar to the comparison screen of Figure 7, where the 
matches may be reviewed and the desired item selected. As discussed in greater detail 
below, buyer 22 preferably interacts with the buyer interface application 40 and back 
office 24, including databases 32 using a web browser. Upon selecting the desired 
item, buyer 22 is preferably immediately reinserted back into procurement system 20 
as shown at point 130, returning to point 98, so that the purchase process may be 
completed. 

A key advantage of the present invention occurs if the desired item is not in 
the master catalog database 32. At point 132 the structured requisition is 
automatically reviewed by back office 24 using the class/attribute/value information 
and normalized database information at its disposal. Based on the information 
provided by the buyer 22, automated systems of back office 24 route the structured 
requisition to potential suppliers as shown at point 134 using communications link 34. 
Communications link 34 was first discussed with respect to Figure 1. Back office 24 
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knows the suppliers associated with particular classes and sub-classes of goods and 
can often fine-tune a requisition submission to very specific suppliers based on 
attributes and values provided within the structured requisition. 

In a preferred embodiment, an electronic mail message is sent to potential 
5 suppliers again using hyperlink and web browser technology, as discussed above. 
Preferably, as discussed further below with respect to Figure 10, supplier 26 interacts 
with a supplier interface application 135 using a web browser. As each supplier 
receives message at point 136, it clicks on the hyperlink and is brought to a screen 
where the structured requisition is provided within application 135. The supplier 26 

10 may provide additional class/value/attribute information to better classify the item 
based on the specialized knowledge of the supplier and the items within its inventory. 
If the supplier has an item that it believes will meet the buyer's structured requisition 
criteria, it then submits a revised requisition as shown at point 138 that is then 
transmitted back to back office 24 by way of communications link 34 as shown at 

15 point 140. The revised requisition includes all of the item related information 
required by buyer 22 to make a purchasing decision. Under some circumstances 
portions of application 135 may even be part of back office 24, but the supplier 26 
still requires some type of interface application such as a web browser. 

Typically, all suppliers 26 receiving a structured requisition are given a 

20 predetermined amount of time to provide a revised requisition. When either the time 
for replying expires or all pre-selected suppliers provide a revised requisition, then at 
point 142 back office 24 compares the revised requisitions to determine the best 
supplier or suppliers for the specific buyer 22. Back office 24 uses a wide range of 
objective and subjective criteria to determine the best supplier(s) including geographic 

25 location, price, reputation, timeliness, and the like. Often, the criteria include those 
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predetermined by the buying organization based on its specific requirements or 
desires. As a result, the wishes of the buying organization are automatically 
considered to expedite the purchase process and reduce both cost and inconvenience. 

Once one or more items are screened as best meeting the needs of buyer 22, 
they are then provided to the buyer as shown at point 128, and discussed above. 

As shown in Figure 8, structured requisition subsystem actually forks at point 
140. The first fork has been discussed above. However, the second fork, related to 
catalog update subsystem 150, is discussed in more detail in Figure 9. 

The use of a normalized parametric search has been discussed above. Every 
item in a catalog database is normalized in terms of class hierarchy with a final leaf 
class being followed by a series of attributes and attribute values. As a result of the 
normalization process, item determination and searching is greatly enhanced. When 
undertaking a structured requisition, the same normalized data is used to the extent 
that it is available to buyer 22. A specialized supplier having expertise with respect to 
the class/attributes/values with which a requisitioned item is associated then further 
refines the structured requisition. Thus, both a knowledgeable buyer 22 and a 
knowledgeable supplier 26 are providing normalized relationships between an item 
and its defining characteristics. The relationships are used to provide selective rule 
updates to the common language generator knowledge base 30 and to an associated 
catalog database 32 using the predetermined rules of the knowledge base, as updated 
from time to time, to convert raw or free form data into the preferred normalized 
format. Thus, once a catalog database 32 is established, the catalog database is 
continuously fine-tuned by suppliers, buyers, and changing market conditions of 
which both are aware. 



19 



65,545-0074 



# 



PATENT 



O 

-Lj 15 
20 



25 



Items may be moved or copied between different databases 32 based on 
various business requirements such as purchase history as tracked by back office 24. 
The information is easily moved by using the common parametric hierarchy disclosed 
in the present invention. 

While a separate knowledge base 30 is illustrated, it is possible to bypass the 
knowledge base 30 completely and update a database 32 directly, so long as the 
class/attribute/value relationships are maintained. An advantage of using a separate 
knowledge base 30, however, is where one or more new rules are specified that are 
later available to be able to normalize free form data. 

As shown in Figure 9, when a revised requisition is received from a specific 
supplier, the revised requisition is reviewed at point 152. The class/attribute/value 
relationships are extracted from the revised requisition and audited by back office 24 
at point 154. The information is audited at point 156 by comparing it to existing 
class/attribute/value relationships to determine if the common language generated 
knowledge base requires one or more new predetermined rules with a subsequent 
refreshing to the catalog database of the updated information available for the item. 
Preferably, the information of several revised requisitions corresponding to a single 
structured requisition is compared to determine normalized consistency among 
various suppliers. Once the audit is completed, a determination is made at decision 
point 158 as to whether updated classes/attributes/values are required for the 
requisitioned item. If not, then the revised requisition is refined using pre-existing 
class/attribute/value information as shown at point 160. Then at decision point 162 
the determination is made as to whether the requisitioned item should be imported 
into the supplier database associated with the specific supplier 26. If yes, then the 
supplier catalog database 32 is updated at point 164 using the updated information 
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associated with the item and the sub-system then ends at termination point 166. If the 
supplier database 32 is not updated, then at decision point 168 the decision is made 
whether to import the requisitioned item into the master database(s) 32. If yes, then 
the master catalog database(s) are updated at point 170 using the updated information 
associated with the item. While not illustrated in the figure, the same approach may 
be used to update the standard buyer catalog database 32 instead of or in addition to 
the master database 32, if so desired. However, once the appropriate catalog database 
is updated, if any, sub-system 150 then ends at termination point 166. 

Catalog database 32 has been designated fairly generically. The database 32 
may be a separate database of items from a specific supplier. Alternatively it may be 
a composite database. When acting as a composite database, it may represent items 
from multiple suppliers that can be organized for and based on the buying habits of a 
single buying organization (e.g., the standard buyer catalog database discussed above) 
or upon the buying habits of a group of related buying organizations (e.g., as in 
hospitals and doctors' offices that are members of a group purchasing organization). 
Therefore, when a database 32 is updated, it may be any one or a combination of 
databases 32 depending on the desires of the supplier buyer 22 or her buying 
organization, suppliers 26, and back office 24. 

At decision point 158 if the decision is made that the normalized information 
associated with the revised requisition is new, then the determination must be made 
whether to revise the common language generated knowledge base at decision point 
172. If the decision is made not to update the knowledge base then sub-system ends 
at termination point 166. On the other hand, if the decision is made to update the 
knowledge base then it is updated with the new information at point 174. Then the 
decision must be made at point 176 whether to update existing catalog entries based 
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on the updated knowledge base. If yes, then the entries are updated at point 178 using 
the updated normalized information that can be associated with the raw or free form 
item data associated with each entry. If no, then the entries are not updated. Then 
subsystem moves on to decision point 162 as discussed above. 
5 The system based interaction between buyer 22, back office 24, and supplier 

26 is explained in greater detail in Figure 10. As shown in Figure 10, buyer 22 
interacts with a buyer interface application 40. Preferably, the interface is web based, 
permitting a buyer 22 to interact with application 40 using a standard web browser 
such as Netscape® Navigator or Microsoft® Explorer. Buyer 22 logs on and off 
2 io from the browser to application 40 as shown by line 200. In turn the log on 
Q information is authenticated with a back office communications interface 202 as 

shown by communications link 28. As illustrated, besides authentication information, 
iy order placement information, structured requisition information, the buyer's supplier 

selection criteria, supplier availability, buyer notification or order status and the like is 
C] 15 also communicated by way of communication link 28 between application 40 and 
O interface 202. Even catalog data base information stored based on pointers provided 

by direct buyer inquiry to a database 32 may be sent using communications link 28. 

After buyer 22 logs on, item selection is accomplished using a hot list, 
advanced text searching, class/attribute/value selection, or a structured requisition 
20 request as discussed above. The item selection process requires that a catalog 
database 32 be queried for information directly by buyer 22 as shown by line 204. An 
order submission is made as shown by line 64 and discussed above, that is passed to 
application 40 from buyer 22. Any required approval process is shown by item 66 
and an order placement made after any approvals is shown by item 68, both of which 
25 were discussed above. Once an order is placed, order status may be passed from 
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interface 202 to application 40 and then to buyer 22 as shown by line 206 until the 
order is fulfilled by a supplier 26. 

If a structured requisition is required, the complete listing of available 
classes/attributes/values is retrieved from the master or global catalog database 32 as 
5 shown by line 208. The structured requisition is passed from buyer 22 to application 
40 by line 210 where the structured requisition is submitted as shown at point 114, 
much as if it were an order. Alternatively, the information may be passed directly 
from buyer 22 to back office 24 by way of communications link 28. If one or more 
items are located using structured requisition subsystem 102, the information 

10 regarding item availability is typically passed from back office communications 
interface 202 to application 40. Next, the information is passed to buyer 22 in the 
form of an electronic message with a link pointing buyer 22 to a server with the 
desired item information. The hyperlinked information may be within back office 24 
or transferred directly to application 40 as desired. 

15 As shown in Figure 10, buyer 22 has direct access to one or more catalog 

databases 32 that are not stored within buyer interface application 40. However, as 
shown by communications link 28 and discussed above, appropriate authentication is 
required before a user can access the catalog databases 32, requiring the use of the 
communication link 28 between buyer 22, application 40 and back office 24 with 

20 database 32. Once authentication is completed, buyer 22 can access database 32 as 
shown. As noted above, application 40 can also directly access database 32 by way of 
communications link 28 for database data corresponding to an item selected by a 
buyer 22 so that an order may be completed. The data elements transferred must be 
sufficient to 1) describe and identify the item including the normalized 

25 classes/attributes/values, part number, description, and 2) provide sufficient 
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information to source the item, including vendor, cost, price, price history, and price 
expiration date. Typically, the data elements are transferred using pointer information 
provided by the inquiry of the database 32 by a buyer 22. 

As shown in Figures 1 and 10, back office 24 itself is broken into a number of 
components. It includes catalog databases 32, back office communications interface 
202, and the common language generator and CLG knowledge base 30. Each of the 
components can readily communicate with each other. For data transfer, a preferred 
mode of communication includes Extensible Markup Language ("XML"), which is a 
subset of the Standardized General Markup Language ("SGML"). HyperText Markup 
Language ("HTML") is appropriate for small data transfers between various portions 
of procurement system 20. 

In general, interface 202 is used to communicate with buyer 22 by way of 
application 40 as noted above. However, when accessing catalog databases 32, buyer 
22 can preferably bypass buyer interface application 40 as long as authentication has 
been completed. Interface 202 is also used to communicate with supplier 26. As 
shown by line 216 all order placement, acceptance, and order status information is 
shared between interface 202 and supplier 26. When structured requisition subsystem 
102 is being used, interface 202 provides the structured requisition as shown by line 
218 and receives a revised requisition as shown by line 220. Supplier item data is 
shown by line 221. Each of these lines comprises a portion of communications link 
34 shown in Figure 1. 

Supplier 26 has only limited contact with buyer 22 as shown in both Figures 1 
and 10. The only direct contact between the two parties is when supplier 26 or its 
agent completes order fulfillment as shown by line 36. 
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Interface 202 uses information it receives from both buyer 22 and supplier 26 
to selectively update catalog databases 32 as discussed with respect to catalog update 
subsystem 150 in Figure 9. 

Knowledge base 30 is the glue that relates an item selection process with the 
items actually stored within a database 32. It is formed using pre-determined rules 
that have been established over time that relate items to class/attribute/value 
characteristics or relationships. These pre-determined relationships are pulled from 
CLG knowledge base 30 as shown by line 222 to be compared with potential 
classes/attributes/values received from supplier 26 as shown by line 220. Selective 
updating of the rules governing knowledge base 30 is shown by line 224. Line 226 
represents the free form supplier item data to be normalized and then loaded into a 
database 32. The data is normalized using the class/attribute/value relationships that 
govern the common language generator and knowledge base 30. In some cases, 
however, a supplier 26 may be able to update its own database 32 without having to 
go through the Common Language Generator, particularly if an appropriate 
parametric structure has been set up using classes, attributes and values. For example, 
a supplier 26 may add or remove attributes or values associated with particular items 
or correct mistakes in attribute values and product descriptions. It may also delete or 
add entire items or groups of items. Under some circumstances a buyer 22 or the 
buyer's organization may be permitted to update its own local database 32 in a similar 
manner without direct involvement of back office 24 other than by providing the 
necessary interfaces. 

Once the supplier data has been normalized using the class/attribute/value 
relationships of the CLG knowledge base 30, it is sent to an appropriate database 32 
as shown by line 230 where the database entries are either imported or updated as 
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shown by line 232. The complete listing of all class/attribute/value relationships used 
by CLG knowledge base 30 are also contained within databases 32 and transferred 
from the knowledge base as shown by line 234. These relationships are used to 
undertake parametric searching and item specifying as discussed above. The 
class/attribute/value relationships are then updated when required as discussed above 
with respect to Figure 9. 

The disclosed embodiments and examples are given to illustrate the present 
invention. However, they are not meant to limit the scope and spirit of the present 
invention. Therefore, the present invention should be limited only by the appended 
claims. 
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